OpenEdge Getting Started:<br />Application and Integration Services Run-time tools

Figure 6–8 shows tools used to run and test a Web service together with a Web service client.

Run-time tools and the Web service URL

When running and testing a Progress 4GL Web service and its client, it is helpful to understand how the tools involved in Web service execution are represented in the Web service URL. There are up to three major components between a Web service client and the Web service it tries to access. All of these components typically participate in the URL path to the Web service and its WSDL file. Listed in their order of appearance in the URL, these components are:

Web server and JSE — Provides the HTTP listener and the JSE to run the WSA. This component optionally participates in the URL, depending on how you install and configure it:

Web-server-based — A full-featured Web server together with a JSE that is integrated with or installed separately from the Web server.

JSE-based — A stand-alone JSE installed with an integrated HTTP listener.

If this component has a Web-server-based configuration, it participates in the URL, mapping to the Web server context, which includes the connection between the Web server and JSE. If it has a JSE-based configuration, there is no URL path component to represent a Web server connection to the JSE. In Figure 6–8, the Web server is separate from the JSE, and its connection to the JSE is represented by its own URL path component, bedrock.

Web application (WSA) — Provides the WSA context for OpenEdge (see Figure 6–6 and the WSA area in Figure 6–8). This is the global context for all WSA instances that run under the control of the same WSA Web application, and is represented in Figure 6–8 by the URL component, quarry.

Servlet (WSA Instance) — Defines the context of each WSA instance, through which individual Web services are deployed and accessed. In Figure 6–8, there are two WSA instances, and they are represented by the URL path components, fred and wsa2.

Thus, a root URL for the WSA instance, fred, maps neatly to the Web service run-time architecture shown in Figure 6–8, as in the following example:

WSA as a run-time tool

http://servicehost:80/bedrock/quarry/fred

At run time, each SOAP request to a Web service is handled by the specified WSA instance. The WSA decodes and encodes SOAP messages according to the Web service interface defined in the WSAD file (WorldWeather.wsad in the figure). It also manages Web service run-time resources as defined by the Web service property settings (WorldWeather.props in the figure).

Tools for testing and debugging

Another tool that you might use to test and debug a Web service client is a SOAP viewer. You can configure a SOAP viewer to intercept all messages sent between the Web service client and the WSA instance. You can then view and possibly modify them (depending on the viewer) before you allow them to continue to their destination. Depending on the viewer, you might have to alter the Web service URL in the client to accommodate the viewer. OpenEdge provides SOAP viewing tools with the installation, but they are also widely available. For more information on testing and debugging Web services and Web service clients, see OpenEdge Development: Web Services .